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(54) Apparatus and method for processing servlets 



(57) A method and apparatus (or operating a local 
server computer of a client-server network includes a 
technique to receive a request from a client computer ol 
the chent-server network. A determination is made 
whether the request requires dynamically generated in- 



formation from a servlet object of the client-server net- 
work If so. a specified servlet object corresponding to 
the request may be uploaded from a remote server com- 
puter of the client-server network. The specified servlet 
object is then executed to obtain dynamically generated 
information corresponding to the request. 
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Description £ 

Brief Description of the invention , l^ta 

This invention relates generally to exchanging information in a clieni-server computer environ. men; \i 0 m . af! |;: 
ularly this invention relates to an improved technique for responcmg to information reauosts a; a server compter' " 

Background of the Invention 

Chent-server comoutcr networks are well known The most prominent cxamole of a client-server comouter network 
is the World Wide Web of computers In a ciiont-sorvor computer network a server compter receives a request (or 
information from a client computer. Web server software operating on the server computer typically retrieve the re- 
quested information from a file stored on a permanent storage device and transmits the file over me network <o the 
client computer that requested the information. The web server software is generally not written using an object oriented 
programming language. Thus, it is not easily extended toprovide new functionality Given the dynamic nature o< todays 
software marketplace, a product's lack of flexibility ana extendib.lity can seriously hinder the marketability of ;ne product 

Current web server software can generate a file dynamically «n response to a request from a client computer 
Typically, the web server receives the request and then forks a Common Gateway Interface (CGi) process to dynam- 
ically create the file Once the file has been created the web server software transmits the file back to the client 
computer. Unfortunately, it is computationally expensive to fork a process each time dynamic information needs to be 
generated 

In view of the foregoing it would be highly desirable (o proviae a web server which dynamically generates infor- 
mation in response to a client computer request, but which does not incur a process start-up exoense while generate 
me dynamic information Furtner it would be highly desirable to provide an ooject .oriented web server environment 
that is flexible and extendible 

Summary of the Invention 

The invention includes a method and apparatus (or operating a local server computer of a client-server network 
The invention includes a technique to receive a request from a client computer of the client-server network A deter- 
mination is made whether the request requires dynamically generated information from a servlet obiect of the client- 
server network. If so. a specified servlet object corresponding to the request may be uoloaded from a remote server 
computer of the client-server network The specified servlet object is then executed to obtain dynamically generated 
information corresponding to the request. 

The servlet objects of the invention pr 0 v,de an object oriented web server environment which is flexible and ex- 
tendible, i he chent-server network of the invention , s populated with the servlet obiects The servlet obiec's operate 
m a continual loop until invoked Thus tnere is no startup overhead associated with execution of the servlet obiects 
5y observing a common applications program interface, the servlet objects can run m any server environment A feature 
. of the invention allows untrusted.ser.vlet objects- to- be executed -in a secure area with the dynamically generate " 
information being passed from the secure area into the remaining server environment. 

Brief Description of the Drawings 

Examples of the invention will now be described in conjunction with the accomoanying drawings in which 
FIGURc 1 illustrates a client-server computer network m accordance with an embodiment of the invention 
FIGURE 2 is a simplified illustration of the interactions between a web server and the servlets 
servel GURE 3 * * ^''^ iliustraEl0n of the "tactions between a web server and a servlet loaded from an external 

FIGURE 4 illustrates processing steps associated with a servlet processing routine 
FIGURE 5 illustrates processing steps associated with a servlet orocessmg routine 
Like reference numerals refer to corresponding parts throughout the several views of the drawings 

Detailed Description of the Invention 

Figure 1 illustrates a cltent-server computer network 20. 

The network 20 includes at least one client computer 22 and at least one server computer 24. The client comouter 
22 and the server computer 24 are connected by a transmission channel 25. which may be any wire or wireless trans- 
mission channel. 
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The client comouter 22 is a stanoard computer includes a Genual Processing Unit (CPU) 30 connecioc to a 
memory (primary and/or secondary) 32 The memor/ 32 stores a numoer of computer programs inducing a 'crowser' 
34 As known in the art. a browser is usee to communicate with remote server computers 2* anc to visually presen: 
the information received from such computers. Tne cneni computer 22 establishes network communications tnrougn 

$ a standard network connection device 35 

The server computer 24 includes standard server computer components, including a network connection cevice 
40. a CPU ^2. ana a memory (primary and/or seconcary) 44 The memory 44 stores a set of computer programs to 
implement the processing associated with the invention The memory 44 stores a web server 45 Tne web server 45 
may be of the type known m the art. which is modified to include the additional programs snown m Pigure 1 That is 

'0 m an embodiment of the invention, a standard web server 45 is modified to include a server acceptor thread 45. a 
connection queue 50. a pool administrator 52. a thread pool 54. servlets 56. a servlet map 55. a security administrator 
50. and boundary servlets 62. 

Figure 2 is a simplified illustration of a server computer 24A constructed in accordance with an embodiment of the 
invention. The figure shows a web server 46 interacting with a set of servlets SoA-SSN. In particular the web server 

'5 45 interacts with the servlets through an application program interface (API). As indicated in Figure 1. the web server 
46 and the servlets 56 are stored m memory 44 The web server 45 may be standard web server software that is 
modified to include the functionality described herein. Eacn servlet 55 is a piece of soltware code which is used to 
dynamically generate information. Each servlet 55 is an instantiated software object watting to be invoked. Once it is 
invoked, it dynamically generates information. Note that this technique of dynamically generating information is distinct 

20 from tne typical process of fetching static information from a permanent storage device. The technique of the invention 
is similar to a CGI script in the sense that it dynamically generates information. However, unlike a CGI script, a servlet 
object of the present invention is instantiated at server stan-up. Thus the servlet can be thought of as operating m a 
continual loop waiting to be executed Observe that after instantiation there is no computational start-up expense when 
the servlet is called. 

25 Figure 3 is a general illustration demonstrating additional features of the invention. Figure 3 illustrates a local server 

computer 24A which receives a request from a client computer (not shown) over transmission channel 25. The web 
server 45 determines that dynamically generated information from a servlet object is required. In this case, tne servlet 
object is not initially on the local server computer 24A. thus it is uploaded by the local server computer 24A from a 
remote server computer 24B using communication link 26. In the example of Figure 3. servlet 56P is passed from the 

20 remote server computer 24B to the local server computer 24A. 

Figure 3 illustrates another feature of the invention. In particular, it illustrates that the uploaded servlet 55P is 
executed in a security area 57 of the local server computer 24A After execution, the results are passed to a boundary 
servlet 60 in the remaining portion of the local server computer 24A. This security feature allows untrusted servlets to 
be safely executed. 

j5 The foregoing discussion provides a general description of the features and benefits of ihe invention. Attention 

now turns to a more detailed description of these features and benefits The left side of Figure 4 illustrates processing 
steps associated with an embodiment cf the invention. The right side of Figure 4 illustrates program components that 
may be used to execute these operations. 

The first processing step shown in Figure 4 is to determine whether a new request has been received (step 70). 

-*o As indicated above, a request is a request for information from a client computer 22 to a server computer 24. The 
operation of a client computer 22 requesting information from a server computer 24 is well known. It is typically per- 
formed using a Uniform Resource Locator or URL. A URL specifies a computer and a file. A typical URL is http;//SU/ 
123. This URL is an instruction to retrieve the file "123" from the State University computer "SU" using the Hypertext 
Transfer Protocol "HTTP". 

J * As shown in Figure 4. a server acceptor thread 45 is used to process each new request. Preferably, the invention 

is implemented as a connection-oriented web server with a server acceptor thread that continually loops while accepting 
requests. Once a request is received, it dispatches the request to a connection queue (step 72). As shown in Figure 
1. the connection queue 50 is formed in the memory of the local server computer 24. 

If no new request is received, then a check is made to determine whether the queue is empty (step 71). If the 

so queue is not empty or a new request has been received, processing proceeds to step 74. Step 74 entails thread pool 
administration operations, whicn are executed by a pool administrator 52. Figure 1 illustrates a thread pool 54. The ' 
thread pool 54 is a pool of threads that are used for request processing. Individual threads fetch and process requests 
from the connection queue 50. The pool administrator 52 operates to ensure that there is a thread for each request in 
the connection queue 50. The pool administrator 52 creates or forks additional threads to handle new requests in the 

ss connection queue 50. If a maximum numoer of threads is reached. Ihe pool administrator 52 blocks new requests from 
entering the connection queue 50. In such a case, the server computer does not receive new requests. On the other 
hand, if a thread has been waiting more than a predetermined period of lime for a request from the connection queue 
50. then the pool administrator 60 will destroy it. Preferably, a new handler thread is created using the butter space of 
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a destroyed handler thread In other words :he mvennon is preferaoly impiementeo by usinc a soocific oun*- m-mer- 
scace for a thread When a thread is destroyed the buffer memory ssace is cleared but it is assigned to a n^V-''- V- 
By reusing allocated memory in this manner this emoodiment of the invention minimis the amount of memory "us^d 
by the system, especially when compared to systems wmcn allocate and deallocate memon/ on a oer recues; basis 
After the thread pool administration operations are performed (step 7J) a thread retrieves a recast from th« 
connection queue (step 76) The thread tnen maos !ne request to a servlet name (step 79) The servlGi may bo specif-ec 
by a URL in which case the mapping process is direct On the other hand some translation process may o* require- 
to identify which servlet will be able to service the request The mapping operation may be oeriormed m one of 
following ways A server administrator m«y specify that some kinds of client requests always mao to a particular servlet' 
ror example, one which talks to a particular database A server administrator may soecify that cart of the client request 
is the name of the servlet. as found in an administered servlets directory At many sites, that directory would be shared 
between servers which share the load of processing for the site's clients Some servers may be able to automatically 
invoke servlets to filter the output of other servlets. based on their admm.stratrve configuration For example particular 
types of servlet output may trigger post-processing by other servlets. perhaos to oerform format conversions ' Properly 
authorized clients may specify the servlet to be invoked, without administrative intervention 

Security operations may also be performed by the thread (step 80). A security administrator 60 may be used to 
identify trusted and untrusted classes of servlets The decision to trust a servlet may be established by a set of rules 
associated with the security administrator 60 For example, the security administrator 60 may decide to trust all local 
servlets and mistrust all uploaded network servlets Untrusted servlets are then executed m the security area 57 as 
shown in Figure 3 The security administrator 50 may also be used to determine if the servlet is authorized to oerform 
predetermined risky operations Security information of this type may be stored in the thread 

JAVA servlets ,n accordance with the invention provide strong security policy support This .s because all JAVA 
environments provide a Secunty Manger wh-ch can be used to control whether actions such as network or f,i e access 
are to oe permuted. By default, all servlets are untrusted and are not allowed to perform ooerations such as access.no 
network services or local files. However, servlets -bu.lt into" the server, or servlets which have been digitally s.qned as 
they were put into JAVA Archive files may be trusted and granted more permissions by the security manager A r« iq „ a , 
signature on executable code indicates that the organization wh.ch signed the code "vouches for ,f ,n some sense' 
Such signatures can't support accountability by themselves, but they do indicate a degree of assurance that may b» 
placed on use of that code. For example, a particular signature from an MIS organization m.ght be required on all code 
which is granted general access to network sendees within a corporate intranet. That signature might only be used on 
code which is strongly believed not to violate particular security polices Extension APIs ,n other languages such as 
C or scripting languages, can't support such fine grained access controls even if they do allow digital signatures for 
their code. 

Alter secunty operations are performed (step SO), the thread is dispatched (step S2 of Figure 5) The dispatch 
operation entails invoking a servlet so that it generates the requested dynamic mformation The d.soatch operation ,s 
one of two types. A decision ,s made to determine whether the servlet is local (step 34) II the servlet is local then the 
local servlet ,s executed (step 86). This results in the generation of dynamic .nformation that is then processed by the 
web server 46 ,n a standard manner. The web server 46 typically passes the information back to the client computer 
_ using known techniques. The exchange of information between a servleLand the web-servers- achieved throuch - 
an application program interface, which is described below. 

If the servlet is no. local, then is uploaded from a remote server 24B (s.ep 88). A decision ,s then made regarding 
whether the uploaded servlet is safe (step 90). Recall thai the security operation s.ep resulted in .he thread acquiring 
information regarding security parameters lor servlets. If there are no securily problems associated with the uploaded 
servlet. then „ « executed locally (step 92) On the other hand if a security problem is identified, .hen .he servlet is 
lT*TJ™ 5 r r * V «' 63 (S ' eP 94) Therea " er d y namical| y 9«™«>»* results are passed to .he non-secun.y 

<Z ,11 I T K 3ry S * ^ 66 US6d ' 0f ' hiS PUfp0SS The boundar y servlet ™V be implemented through 
the use of stubs and subcon.rac.s or through o.her -fire wall" techniques known in the art. After the servlei is executed 
processing returns to step 70 of Figure 4 executed. 

of ,Z h LZ7T ?' T ' nVen,i0n n ° W b6en ' U " y deSCr ' bed AMen,ion now ,urns 10 a ™ e Pabular discussion 
of .he serv.e. ob,ec.s that are used ,n accordance with .he invention and an embodiment of the applicanon program 

C T H° n SeMel °° ieC,S AS indlCa,ed 3b0Ve lhe ° b < ecls are <*U ™ s°f.ware 

inl, h p k? '° dynam,Cal, V 9 enera,e "formation. They are ms.an.ia.ed ob,ec.s that s,< in a loop wai.mg to be 
" V 7 Plemented 38 ° b * eCt b V<**> >» ,he JAVA- programming language. .Ms wet, nown 
. 1 programmmg language ,s used to implement "applets- on a client computer. An -applet- is executable 

JAVA ob,ect bytecodes .hat are used to generate a graphica. display on a client computer. The servlets embodying the 
present invention are executed on lhe server side and do not have graphical content 

„ * SerVle, ! S ,ypi f ally ^tan.ia.ed on server startup. In .he alternative, the servlet may be instan.,a.ed under a 
prede.erm,ned set of conditions or by client invocation. The servle. may be insinuated and executed by us£g its Ur! 
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(eg htlp //host' < servlet U?.L>) The hup protocol suopons :ne passing of arguments tr.us arguments may ee Das sec 
to the servlet fe g hi;p.//hosi« < serviet U. = .L>* ? < arguments >; The srcoenies co:e-i is a JAVA srcgramming language- 
properties class which comonses a set ol "name value" oairs A sysiem administrator can pass arguments to *n in- 
stantiated HttpServlet objeel through the properties object In ims way tne system administrator can "customize * an 
HttpServlet (or a particular server at a particular site For examde the system administrator can pass tne Hxcservio: 
object site specific information about me network location ol a data case wmch stores documents tr.a; will be recucstec 
by client processes across the network or the amount ol memory available m system suffers wmch will oo usee lor 
processing the server administrator 

Once instantiated, a servlet loops until the server is snut off or a destroy method is called on tne servlet by tne 
server Since the servlet operates m a continual loop as it waits lor requests to act upon the server computer avoids 
the overhead of creating and destroying the servlet between requests to the servlet. In addition, keeping serviets aiive 
between requests allows serviets to pass data and communicate amongst themselves For example serviets can 
maintain data about a user between sessions by the user This data can be shared among different serviets in order 
to customize a working environment within whicn the user works II serviets were created and destroyed on a per 
request basis, it would be much more difficult, if not practically impossible, (or a servlet to unoerstand the environment 
within which it runs and utilize this knowledge to provide improved processing capabilities The server computer can 
call a destroy method on the servlet when some resource limit in terms of time memory etc is reacned 

The servlet application program interface (API) establishes a standard for interfacing serviets with information 
servers, such as web servers The servlet API contains methods lor initializing a servlet. processing the request, celling 
servlet information, and destroying the servlet The servlet API allows platform independent serviets An example 
servlet interface is as follows 

Servlet interface: 
interface HttpServlet { 

Initialize (ServletContext, ServcrPropenies); 

Service(HttpRequest, HttpResponse); 

DestroyO; 

} 

The server computer passes objects that implement the "HttpRequest". while the servlet returns an "HttpResponse" 
object. The "ServletContext" interface is used to exchange information with the server environment. Some of the meth- 
ods on the "ServletContext" object are "Getserver()* and "GetServlets()\ "GetServer" returns a pointer to the parent 
server within which the instantiated Httpservlet runs. Using this pointer, the HttpServlet object can find out information 
about its parent server. The "GetServiet" method returns pointers to the serviets running on the parent server. The 
"ServerFroperties" interface is used to exchange information regarding specific server properties established by a 
server administrator 

Serviets support the familiar programming model of accepting requests and generating responses. The following 
is a simple servlet defining a single method called "service" 
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import Java. servlet.*; 

public class MyServlet extends GenericServlet { 

public void service ( 

ServletRequest request, 
ServletResponse response 

) throws ServletException, IOException 

{ 



} 



} 



The sen/ice method is provided with Request and Response parameters. These parameters encapsuiate the aaia sent 
by the client thereby allowing servlets lo report status information, such as errors Servleis normally retrieve most of 
their parameters through an input stream and send their responses using an output stream 

ServletlnputStream in = request. getlnputStream () 
ServletOutputStream out = response. getOutputStream (); 

These input and output streams may be used with data in whatever formal is appropriate. For example an applet and 
servlet might exchange data using object serialization. HTML, or any number of image formats. 

Since servlets are JAVA objects, they have instance-specific data. This means that in effect servlets are independ- 
ent applications running within servers without needing the complexity of additional classes (which are required by 
some alternative server extension APIs). Servlets have access to some servlet-specific configuration data at initiali- 
zation time This allows different instances of the same servlet class to be initialized with different data, and be managed 
as differently named servlets The data provided at initialization time includes an area where each instance keeps its 
persistent instance-specific state. 

Building upon the previous simple servlet examples, the following program code is an example of a servlet that is 
used to send Hypertext Markup Language (HTML) text when it is invoked; 
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public class SimpleServlet extends GenericServiet { 
public void service(ServletRequest req, ServletResponse res) 
throws ServletException, IOException 

{ 

res.setContentType(''text/htmr); 

PrintWriter out = new PrintWriter(res.getOuiputStream()); 
out.pnntln("<HEAD> < TITLE > SimpleServlet Output 
</TITLE> </HEAD> <BODY>"); 

out. printing <hl > SimpleServlet Output </hl>"); 
out.println("<P>This is output from SimpleServlet."); 
oui.print]n("</BODY> w ); 
out.flush(); 

} 

public String getServletlnfoO { 

return "A simple servtet"; 

} 

} 

The following program code is an example of a servlet thai uses the finger protocol to query information about 
users on specified host computers. The query string parameters < it > user < /it >. < tt > hosts < At >. and < tt > verbose 

< /tt > can be used to specify the user and hosts to query The parameter <tt> user </U> is the user name. <tt> hosts 

< /tt > is a comma-separated list of host names to query, and <tt> verbose </tt>. if specified, will cause verbose output 
to be generated. For example. <pre> http/goa/finger.html?user=dac&hosts=eno.doppio&verbose=yes </pre> will re- 
quest full information about user *dac" on both hosts "eno" and "doppio". 
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public 

class FingerServlet extends GenericServlet { 
/* 

* Port number for finger daemon. 
V 

static final int FINGER_PORT = 79; 
/** 

* Handles a single finger request from the client. 
*/ 

public void servicc(ServletRequest req, ServietResponse res) 
throws ServletException, IOException 

{ 

String user = req.getParameter("user M ); 
String hosts = req.getParameter("hosts"); 
String verbose = req.getParameter("verbose"); 
res. setCon ten tType(" tex \J html" ) ; 

PrintStream out = new PrintStream(res.getOutputStreamO); 
out. println(" < html > "); 

out. printing < head > < title > Finger Servlet < /title > < /head > ") 
out. printing <body > "); 
out.printlnf < h2 > Finger results: < /h2 > "); 
outprintln(" < pre > "); 
if (hosts == null) { 

finger(out, user, null, "yes M .equalsIgnoreCase(verbose)); 
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} else " { 

StringTokeniier st = new StringTokenizer(hosts, V); 
while (st.hasMoreTokensO) { 

Siring host = st.nexiToken0; 

out.println(T + n ost + "]"); 

try { 

fingcr(out, user, host, 

"yes\equaisIgnoreCase(verbose)); 

} catch (IOException c) { 
out.println(c); 

} 

out.println(); 

> 

} 

out. printing </pre> M ); 
out.printlnf </body> </html> "); 

} 

/" 

* Sends finger output for a user and host to the specified output 

* stream. 
*/ 

void finger(OutputStream out, String user, String host, boolean verbose) 
throws IOException 

{ 

// open connection to finger daemon 
Socket s; 

if (host == null) { 

s = new Socket(InetAddress.getLocalHost(), 

FINGER_PORT); 

} else { 

s = new Socket(host, FINGER_PORT); 

} 

// send finger command 
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PrintStream ps = new PrintStream(s.getOutpu:Stream()); 
if (verbose) { 

pS-printCVW); 

} 

if (user ! = null) { 
ps.print(user); 

} 

ps.print("\r\n"); 
ps.flushO; 

// copy results to output stream 
InputStream in = s.getInputStream(); 
byte[] buf = new byte [512]; 
int len; 

while ((len = in.read(buf, 0, buf.length)) != -1) { 
out. write(buf, 0, len); 

} 

s.closeQ; 



^Those skilled in the art will aopreciate that servlets which are being used with ihe HTTP protocol may support any 
HTTP method, including GET POST HEAD, and more. They may redirect requests to other locations and send HTTP- 
specific error messages. They can get access to parameters which were passed through standard HTML forms, m- 
eluding the HT i P method to be performed and the URI. which identifies the destination of tbe .reauest^ 

As indicated above, one of the biggest performance features of serviets is that they do not require creation of a 
new process for each request. In most environments, many servlets run in parallel within the same process as the 
server. When used in such environments with HTTP servlets provide compelling performance advantages over both 
the CGI approach and the Fast-CGI approach. This is because servlets have a small computational expense during 
thread context switches. Since in most environments servlets can handle many client requests each time they are 
initialized, the cost of the initialization is spread over many methods. All the client requests to that service have the 
opportunity to share data and communications resources, benefitting more strongly from system caches. 

Those skilled in the art will appreciate that the servlets embodying the invention can be used to dynamically extends 
Java-enabled servers. The servlets provide a general framework for sen/ices built using the request-response para- 
digm. The servlets can provide secure web-based access to data which is presented using HTML web pages and they 
can be used for interactively viewing or modifying that data using dynamic web page generation techniques. 

The servlets embodying the invention may be used to provide customized multiuser services for customer bases 
The serviets are also flexible enough to support standardized services, such as serving static web pages through the 
HTTP (or HTTPS) protocols, and proxying services. Since they are used for dynamic extensibility, they may be used 
m a plug-tn style, supporting facilities such as search engines and semi-custom applications, such as web-based order 
entry or inventory systems. 

Although the servlets are preferably written in JAVA, the servtet clients may be written in any language When 
servlets are used in the middle tiers of distributed application systems, they can in turn be clients to other services 
written in any language. 
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Those skilled in the an will apc-reciate that serviets may be usee in several modes. The oasic mode is at tne core 
o( a request/response protocol in addition servieis may oe specialized to support protocols sucn as HTTP in HTTP 
based apDlicattons. serviets are portable complete, and much more efficient replacement for CGI based extensions 
Also m HTTP applications serviets may be used with HTML server sice includes to dynamically generate pari of a 
web document. 

The foregoing description for purposes of explanation, usee specific nomenclature to provide a thorough under- 
standing of examples of the invention However, n will be apparent to one skilled in the art mat the specihc details are 
not required in order to practice other examples of the invention. In other instances, well know circuits and aevices are 
shown in block diayram form in order to avoid unnecessary distraction from the underlying principles Thus, the fore- 
going descriptions of specific embodiments of the present invention are presented for purposes of illustration and 
description 



Claims 

1 . A method executed by a local server computer under the control ol a program, said local server computer including 
a memory for storing said program said local server computer forming a portion of a client-server network, said 
method comprising the steps of. 

receiving a request from a client computer of said client-server network; 

determining that said request requires dynamically generated information from a servlet object of said client- 
server network: 

uploading from a remote server computer of said client-server network a specified servlet object corresponding 
to said request; and 

executing said specified servlet object to obtain dynamically generated information corresponding to said re- 
quest. 

2. The method of claim 1 further comprising the step of passing dynamically generated information from said specified 
servlet object to a web server operating on said local server computer, said passing step being facilitated with an 
application program interface. 

3. The method of claim 2 wherein said application programming interface specifies techniques for performing at least 
one of the following operations: initializing a servlet object, executing a servlet object, and destroying a servlet 
object. 

4. The method of claim 2 wherein said specified servlet object and said application program interface are specified 
as object bytecodes in the JAVA programming language 

5. The method of claim 2 further comprising the step of sending said dynamically generated information from said 
web server to said client computer. 

6. The method of claim 1 wherein said executing step includes the steps of 

executing said specified servlet in a security area of said local server computer; and 
• passing said dynamically generated information from said security area to a non-security area of said local 
server computer. 

7. The method of claim 1 wherein said local server computer stores a plurality of servlet objects, each of said servlel 
objects continuously operating until invoked in response to a specified request from a client computer. 

8. The method of claim 7 wherein said plurality of servlet objects pass data to one another. 

9. The method of claim 7 wherein said selected servlet objects of said plurality of servlet objects are instantiated at 
the start-up of said local server computer. 

10. The method of claim 7 wherein selected servlet objects of said plurality of servlel objects are instantiated in re- 
sponse to a demand from said client computer. 
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11. The metnod of claim 7 wherein selected servie; objects of sac plurality of servlet comets are instantiated in .-o- 0 
sponse to an activated servlet URL 

12. The method of claim n wherein saia servlet URL includes arguments 

1 3. The method of claim 1 wnerem said receiving step includes the stop of storing said reoues; m a connection queue 

1 4. The method of claim 1 3 wherein sa.d aetermmmg step includes the step of selecting a handler tnroad from a pool 
of handier threads to execute said determining step 

1 5. The method of claim 1 4 further comprising the step of operat.ng said pool of handler threads by selectively creating 
a new handler thread and destroying an old handier thread 

16. The method of claim 15 wherein said operating step includes the step of reusing a buffer memory space of said 
' 5 old handler thread for said new handler thread 

1 7. A computer readable memory that can be used to direct a server computer of a cheni-server computer network to 
function in a specified manner, comprising' 

20 a f,rst set of instructions to receive a request from a client computer of said client-server network 

a second set of instructions to determine that said request requires dynamically generated information from 
a servlet object of said client-server network: 

a third set of instructions to upload from a remote server computer of said client-server network a specified 
servlet object corresponding to said request, and 

25 a fourtn set of instructions to execute sa.d specified servlet object to obtain dynamically generated information 

corresponding to said request. 

18. The apparatus of claim 17 further comprising a fifth set of instructions to pass, through an application program 
interface, dynamically generated information from sa.d specified servlet object to a web server operating on sa.d 

30 local server computer. 

19. The apparatus of claim 1 8 further comprising a sixth set of instructions to pass said dynamically generated infor- 
mation from said web server to said client computer 

3S 20. The apparatus of claim 1 7 further comprising a seventh set of instructions to store a plurality of servlet objects on 
sa.d server computer each of said servlet objects cont.nuously operat.ng until invoked in resoonse to a specified 
request from a client computer. 

. „ _ 2 „1. Jhe apparatusof claim 20 wherein said seventh set of instruciions-include instructions to pass data between said - - - 
~° plurality of servlet objects. 

22. A computer readable memory that can be used to direct a server computer of a client-server computer network to 
function in a specified manner, comprising: 

45 a first set of instructions to receive a request from a client computer of said client-server computer network 

a second set of instructions to determine that sa.d request requtres dynamically generated information from 
a servlet object of said server computer: 

a third set of .nstructions to execute said specified servlet object to obtain dynamically generated information 
corresponding to said request: and 
*> a fourth set of instructions to pass sa.d dynam.cally generated .nformation to said client computer. 

23. The apparatus of claim 22 wherein sa.d second set of instructions include .nstructions to interpret a servlet URL 
corresponding to said request. 



ss 



24. The apparatus of claim 22 where.n said second set of .nstruct.ons include instructions to interpret a servlet URL 
with arguments. 

25. The apparatus of claim 22 further comprising a fifth set of instructions to store a plurality of servlet objects on said 
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server commute: eacn of said servlet objects continuous!;/ operating until invokes m response to a specifies reeuesi 
from a client computer 

26. The apparatus of claim 20 wnerem said film set of instructions include instructions to pass cata between said 
plurality of servlei objects. 

27. A client-server computer network comprising 

a client computer to generate a requesi: and 
a server computer to 

determine that said request requires dynamically generated information from a servlei coject of said server 
computer, 

execute said specified servlet object to obtain dynamically generated information corresponding to said 
request, and 

pass said dynamically generated information to said client computer. 

28. The apparatus of claim 27 further comprising a remote server computer storing a set of serviel objects tnat can 
be passed to said server computer 

29. The apparatus of claim 27 wherein said server computer stores a plurality of servlet objects, each of said servlet 
objects continuously operating until invoked m response to a specified request from said client computer 

30. The apparatus of claim 29 wherein said plurality of servlet objects pass data between themselves. 
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(Fro.r. step SO; Figure 4) 
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